大夥兒先坐下，大孫女，快幫客人都沏上一杯暖呼呼、香氣撲鼻的琥珀熱茶。

看著這晚霞灑落的溫馨院落，阿公坐在藤椅上，總會想起以前我們在做金融合規時的那些老故事。小孫女剛剛還在阿公身旁撒嬌，現在跑去跟懂事的姐姐在院子裡跑來跑去、玩得正開心呢。看著她們無憂無慮的樣子，阿公心裡就在想，我們以前拼了命做系統，不也就是為了讓大家能省點心、少犯點錯，下班了能早點回家陪家人嗎？

你們這些年輕人天天掛在嘴邊的「FinTech」，聽起來新潮，但其實核心道理跟阿公以前做合規（Compliance）是一樣的。今天，阿公就用這杯熱茶的功夫，慢條斯理地跟你們講講這門學問：

Day 7：合規系統的大哉問：為什麼我們要將 LCR 估算從 Excel 遷移至 Web 系統？

🚨 痛點場景 —— 那些年，我們被 Excel 支配的流動性惡夢

「流動性覆蓋比率（LCR）」，這五個字在金融圈子裡，那可是監理機關盯得最緊的重中之重，是決定一家銀行能不能活下去的生命線。簡單來說，它就像阿公在鄉下過日子，家裡隨時得存點現金、備點乾糧，萬一遇到颱風天，就算十天半個月不出門，也絕對餓不著。金融機構也是一樣，要隨時確保在壓力情境下，手頭上的「高流動性資產」夠應付未來三十天內的資金淨流出。

可是啊，以前這個生命線指標是怎麼算出來的？說來好笑，大家居然都依賴財務部、風管部等各個業務單位用 Excel 填報，然後用 Email 往返 寄送，最後再由我們風控彙整人員，在漫天飛舞的收件匣中用 人工去彙整。

這帶來了三大災難，阿公每次想起來都直搖頭：

• 版本混亂：這就像阿公的大孫女和小孫女都在畫畫，大孫女畫完改了一筆，小孫女又拿去蓋，最後阿公根本分不清哪一張才是最新的完成版。Email 寄來寄去，每個人手上的 Excel 命名都不一樣，有人叫 LCR_預估_final.xlsx，有人叫 LCR_預估_final_v2_真的final.xlsx。一不小心彙整錯版本，報給主管的流動性評估數字可就全錯了，這在法規上是要出大紕漏的。
• 無審計軌跡（Audit Trail）：Excel 就好比一塊黑板，誰都能拿板擦去擦掉重寫。是誰在什麼時候改了資料？為什麼這個月的預估假設和上個月不一樣？完全沒有紀錄。阿公常教導孫女，做人做事要腳踏實地、一步一腳印，但 Excel 偏偏「踏雪無痕」，一旦出了事被內部稽核或外部監理機關查核，根本追溯不出到底是哪個環節出了問題。
• 公式被不小心修改：Excel 的儲存格是活的，每個人點進去手一滑，就可能不小心修改到複雜的折現率或計算公式。這就像小孫女不小心把我藤椅下的螺絲擰鬆了一顆，外表看起來好好的，阿公一坐上去，藤椅可就塌了！Excel 公式一旦被誤動，算出來的 LCR 數字可能差之千里，卻極難被人工察覺。

🛠️ 架構實作 —— 搬新家！打造標準化 LCR 控管 Web 系統

既然舊草屋漏水，我們就得合力蓋一棟穩固的磚瓦房。這套標準化的 LCR 控管 Web 系統，就是我們的避風港。

我們不再讓大家用 Email 寄檔案了，而是建立一個 集中式資料庫（Centralized Database）。並且，我們利用角色權限控制（RBAC），將平台上的所有人分成了三種角色：

• 資料提供者：他們就像是挑水的人。他們只能在線上表單填寫自己的部分，並查看自身的提交狀態，再也不能隨意插手別人的格子。
• 資料彙整者（如 LCR 小組）：這就像是村子裡的總管。他們負責發起每一期的任務，設定提供期限。他們能在一個畫面上即時看到誰交了、誰逾期，並且一鍵把所有數據彙整成試算基礎資料，免去人工對帳的痛苦。
• 風控審查者（如管理層與經理）：這就是坐在大堂上的決策者。他們有一個唯讀的儀表板，可以清楚地審閱 LCR 預估結果與呈報依據，判斷是否需要進行更進一步的決策評估。

所有人都在這同一個平台上操作，系統會自動在後台幫我們把關：

• 即時進度追蹤：儀表板上像一盞盞明燈，亮著「已提供」、「未提供」或「逾期」三種狀態，誰沒交，一目了然。
• 自動提醒與告警：窗口不用天天打電話催了，期限快到時，系統自己會發 Email 給沒交的單位，一過期限立刻發出逾期告警並通知彙整窗口。
• 歷史修改軌跡（Audit Log）：阿公最喜歡這個。我們在資料庫裡建立 T_AUDIT_LOG 這張表。任何人的發起、提交、檢核、修改、匯出等關鍵動作，系統都會清清楚楚記錄下：是誰、在什麼時間、做了什麼動作、修改前後的值是什麼。有了這個，審計軌跡明明白白，徹底消除人工彙整的漏洞。

💡 避坑指南 —— 順著老習慣的「溫柔前端」，配上「鋼鐵後端」

不過啊，阿公活了這把年紀，最明白一個道理：人最難改的就是『習慣』。金融業的同仁們，天天都在和 Excel 打交道。你突然要把他們習慣用的 Excel 收走，換成一個全新、生硬的 Web 網頁，大家一定會抱怨連連，採用意願極低，甚至私底下還是偷偷用 Excel 互傳，那系統就白做了。

這就像我那愛撒嬌的小孫女，你硬逼她吃青菜，她一定哭鬧；但如果阿公把青菜剁得碎碎的，混在她最喜歡的肉丸子裡，她就吃得開高興興。這就是順應習慣的溫柔之道。

所以，在設計系統時，我們有兩大心法：

1. 前端的溫柔：保留與原 Excel 類似的輸入網格（Grid）：
   當使用者點進填報網頁時，映入眼簾的不要是冷冰冰、一格一格往下拉的生硬表單。我們要保留像是 Excel 一樣的網格輸入介面（Grid）。使用者可以直接在上面打字、切換儲存格，甚至支援從他們本機的 Excel 複製、直接貼上（Paste）到網格裡。他們用起來覺得跟以前一樣親切，上手的阻力自然就小了，這就是「以人為本」的設計。
2. 後端的鋼鐵：使用 API 進行最嚴格的 Schema 檢核：
   前端雖然看起來像溫柔的 Excel，但後端可得是鐵面無私的執法官。只要使用者一按下儲存或提交，後端 API 就會透過嚴格的 Schema 檢核（例如 Zod Schema 或後端邏輯）進行瘋狂的交叉比對：
   • 資料基準日檢核：確認提供單位填的基準日，是不是跟這次期別任務規定的日期一模一樣（不符 → 直接打槍，判定為異常）。
   • 完整性與必填檢核：看看該填的預估數、附件有沒有齊全，必填欄位有無缺漏。
   • 預估標記與假設檢核：如果填的是預估數，必須明確勾選「是否預估」，且「假設條件」欄位絕對不能留白。

只要有一項沒通過，後端 API 就會拒絕寫入，並在畫面上顯示溫柔但明確的中文警示，要求對方補正。

透過這種「前端溫柔、後端鋼鐵」的設計，同仁們填寫得順心，我們收集到的資料品質又比以前人工檢查還要精準、還要安全！這才是系統遷移合規的最高境界啊。